As reliance on computers and computers systems in all aspects of daily life continually expands, so do the concerns about data security. Increasingly the public, government agencies and corporations call on those that generate data and hold data to insure its integrity and privacy. Many private and public organizations have issued standards and procedures to establish protocols that those entrusted with data need meet in order to receive, work with and retain the data of others. The growing prevalence of cloud based systems further heightens such concerns.
Government agencies are particularly concerned with data security and integrity. For example the US Department of Defense (DoD) issues directives for the Information Assurance (see DoDI 8500.01.) and presently directs that the Defense Information Systems Agency (DISA) “Develops and maintains control correlation identifiers (CCIs), security requirements guides (SRGs), security technical implementation guides (STIGs), and mobile code risk categories and usage guides that implement and are consistent with DoD cybersecurity policies, standards, architectures, security controls, and validation procedures. This is to be done with the support of the NSA/CSS, using input from stakeholders, and using automation whenever possible.” Complying with these protocols is essential for any organization wishing to work with the Defense Contract Management Agency. As cybersecurity threats are increasing in frequency and scope, government agencies are requiring increased cybersecurity awareness and enhanced cybersecurity postures among businesses who wish to work with government agencies. Beginning in 2015, the DoD DFARS (Defense Federal Acquisition Regulation Supplement) subpart 204.73 was amended for all companies with DoD contracts or subcontracts. This clause requires adequate safeguarding of controlled technical information and reporting of cybersecurity incidents; meaning businesses who do not meet these cybersecurity compliance requirements no longer have the ability to bid on government contracts. Furthermore, companies who are found negligent or noncompliant in these required practices may lose existing, long-term contracts or face system shutdown due to noncompliance.
Along with the government private and public organizations have established regulations and guidelines regarding protection of sensitive information using published standards. These standards, published as security information and guideline requirements, are designed to protect a myriad of different businesses, but all of these regulations and guidelines share the common goal of combating cybersecurity risk and vulnerabilities. The sets of guidelines for software security continue to expand. There are many notable, examples of published security information and guideline requirements each referred to herein as a software security guideline set (SSGS).
SSGSs published by the National Institute of Standards and Technology (NIST) include:                a. NIST Special Publication 800-53 “Security and Privacy Controls for Federal Information Systems and Organizations.” This SSGS contains the steps in the Risk Management Framework that address security control selection for federal information systems in accordance with the security requirements in Federal Information Processing Standard (FIPS) 200. This includes selecting an initial set of baseline security controls based on a FIPS 199 worst-case impact analysis, tailoring the baseline security controls, and supplementing the security controls based on an organizational assessment of risk. The security rules cover 17 areas including access control, incident response, business continuity, and disaster recoverability.        b. NIST Special Publication 800-171 “Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations.”: This SSGS covers the protection of Controlled Unclassified Information (CUI) while residing in nonfederal information systems and organizations is of paramount importance to federal agencies and can directly impact the ability of the federal government to successfully carry out its designated missions and business operations. This publication provides federal agencies with recommended requirements for protecting the confidentiality of CUI.        
In relation to credit cards there is the PCI DSS “Payment Card Industry Data Security Standard.” This SSGS is a proprietary information security standard for organizations that handle branded credit cards from the major card schemes including Visa, MasterCard, American Express, Discover, and JCB. The PCI Standard is mandated by the card brands and administered by the Payment Card Industry Security Standards Council. The standard was created to increase controls around cardholder data to reduce credit card fraud.
The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) specifies and SSGS as ISO/IEC 27001:2013 “Information technology—Security techniques—Information security management systems—Requirements.” ISO/IEC 27001:2013 specifies the requirements for establishing, implementing, maintaining and continually improving an information security management system within the context of the organization. It also includes requirements for the assessment and treatment of information security risks tailored to the needs of the organization. The requirements set out in ISO/IEC 27001:2013 are generic and are intended to be applicable to all organizations, regardless of type, size or nature.
There is also an SSGS from the ITIL “Information Technology Infrastructure Library 2011 Edition.” ITIL describes processes, procedures, tasks, and checklists which are not organization-specific, but can be applied by an organization for establishing integration with the organization's strategy, delivering value, and maintaining a minimum level of competency. It allows the organization to establish a baseline from which it can plan, implement, and measure. It is used to demonstrate compliance and to measure improvement.
Another SSGS is the FFIEC Assessment “Federal Financial Institutions Examination Council Cybersecurity Assessment Tool.” The content of the Assessment is consistent with the principles of the FFIEC Information Technology Examination Handbook (IT Handbook) and the National Institute of Standards and Technology (NIST) Cybersecurity Framework, as well as industry accepted cybersecurity practices. The Assessment provides institutions with a repeatable and measurable process to inform management of their institution's risks and cybersecurity preparedness.
An SSGS in the field of health care is the HIPPA “Health Insurance Portability and Privacy Act (HIPPA) Security Rule.” In the health care space, entities (covered entities and business associates) regulated by HIPAA must comply with the HIPPA Security Rule to ensure the confidentiality, integrity, and availability of electronic protected health information (ePHI) that they create, receive, maintain, or transmit.
At present, determining whether a computer system meets and/or deviates from a particular SSGS involves substantial human evaluation of many lines of guideline codes and various manual steps. Although some attempts have been made to automate these procedures they have generally failed because these attempts have been incomplete, inaccurate, or have failed to keep abreast of the fast-paced nature of continuously evolving cybersecurity threats. The software approaches to automate SSGS compliance status are also problematic since they rely more extensively on uploaded or installed third-party software and specialized graphical user interfaces.
Most involve either installing a client side “agent”, which is a small software application that runs on each OS instance and acts as an “agent” or representative for the compliance software. The agent is used with a third party application which usually runs on its own server to determine cybersecurity compliance. Other methods involve using third party software applications that would need to be installed locally or on a separate server and require privileged level access to login to those operating system instances under evaluation.
Moreover, with respect to the known programming attempts to automate SSGS compliance, these attempt use complex search and interrogate software (SAI) on the computer system under review for SSGS compliance (hereinafter “Subject System.”) Depending on the particular vendor, such SAI software may easily contain more than 100,000 lines of code to find data and analyze the operational parameters and function of the targeted computer or computer system. This is a very conservative estimate when one considers that the average iPhone app will contain 500,000 lines of code.
This SAI software approach also adds complexity by requiring adaptability in configuration for the Subject System” and overcoming security safeguards of Subject system. The resulting complexity of the SAI software combined with the aforementioned need to keep it updated have deterred attempts to automate the portions of SSGS compliance review that may otherwise lend itself to such automation.
The time intensive methods that are generally now employed to determine a security status do not meet the need of staying abreast of threats to systems and data security. Each status check only gives a snap shot of a Subject System's status at an instant in time. Security threats occur at ever increasing frequency and protocols need to rapidly advance to meet the dynamic nature of such threats. Thus, a system's security status can be out of date almost as soon as it's determined. Therefore, new methodology is needed to give status determinations at a frequency not currently deliverable by present methods.
Reliable methods and systems are sought that can deliver the security status of a Subject System in much faster way than is presently available.